1. Field of the Invention
This invention relates in general to object server systems, and in particular to optimized caching of Structured Query Language (SQL) data in an object server system.
2. Description of Related Art
Object server computer systems are composed of collections of objects. Some object server computer systems use a relational database to store the data associated with one or more of the objects. The data in the relational database is retrieved from the relational database, manipulated, and stored in the relational database through use of an object interface to the relational database.
One of two approaches is typically taken to read and write data from the relational database. A first approach requires that a developer creating an object also generate read and write methods as part of the object implementation for reading or writing the data from and to the relational database. With the second approach, the object server computer system provides a function that performs the data read and write operations when the user describes, in a declarative manner, how the data attributes of the object map to the relational database.
One problem common to either approach is optimizing the movement of multiple objects to and from the relational database. Another problem common to either approach is determining when to lock the relational database so that updates that occur through the object interface are done with data integrity without performing excessive locking at the relational database. Excessive locking of data may degrade relational database concurrency. This is a particular concern with object-oriented computer systems where application programs tend to create long running transactions.
Yet another common problem is directed to providing a system in which relational data is represented by objects and which runs in a multi-threaded, multi-user object server environment.
Some computer systems that attempt to solve some of the problems mentioned above are: Sparky, which is written in SmallTalk by the International Business Machines (IBM) Object Technology Practices; Persistence, which is from Persistence Software; Java Relational Binding by O2 Technology; and DBConnect written jointly by IBM Santa Teresa Laboratory and Object Design, Inc. These computer systems map relational data to objects.
Some of the computer systems provide use of prefetch (i.e., preload options). Under a prefetch option, when data for an object is read from a relational database, data is also read for related objects for which there is a high likelihood of access. To read data for related objects, SQL SELECT and JOIN operations are used. The use of SQL SELECT and JOIN operations results in a more efficient access to a relational database than a series of individual SELECT statements to retrieve data for multiple objects.
Some of the computer systems implement pessimistic caching where data is read from the relational database during each transaction and the data remains locked in the relational database until the end of the transaction. If the data is needed by the next transaction, the data is reread from the relational database.
Other computer systems allow optimistic caching where data is unlocked at the relational database and remains in memory at the object server and can be reused by multiple transactions without rereading it from the relational database. A developer issues explicit refresh calls when the developer needs current data.
Some of the computer systems provide solutions that are designed to work in a client desktop environment where the client is connected directly to a relational database server. Other approaches make use of an object server (sometimes called tier 2 in a 3 tiered system) that is placed between the client and the relational database. This allows the object-oriented application program to execute at the object server and have a thin client.
Some of the approaches above do not track updated objects. When the object developer makes an update to an object, additional calls are required to apply the update to the relational database.
Moreover, when running in a multi-threaded, multi-user object server environment, the approaches above require that data be locked either at the database level or within the object server for serialization and data integrity. Use of such locks in a long running transaction can degrade system concurrency.
There is a need in the art for improved relational database access in a multi-threaded, multi-user object server environment.